1. Field of the Invention
The present invention relates to computer software, and deals more particularly with a method, system, and computer program product for providing synchronous execution between objects written in an object-oriented programming language and business logic written in a procedural programming language, while executing under control of an interactive test facility for debugging purposes.
2. Description of the Related Art
Testing is an important part of the software development cycle. The motivation for testing software is to raise the quality and reliability of the program, and to establish confidence that the program does what it is supposed to do. Assuming that programs contain errors, the purpose of testing is to find as many of the errors as possible. Thus, testing may be considered as the process of executing a program with the intent of finding errors.
Many interactive test facilities, or xe2x80x9ctest debuggersxe2x80x9d, provide features that allow users to animate (i.e. display, and step through the logic of) the business logic which is invoked by graphical user interface (GUI) applications, where that business logic is often written in a procedural programming language. This is typically done using an event-driven facility which knows how to become active when a specific event from the graphical user interface causes invocation of a business logic code component. When the GUI event is triggered, a debugger for procedural code is invoked. A window (referred to herein as a xe2x80x9ctest monitor windowxe2x80x9d) is then displayed to enable the developer to interact with and control the business logic debugging. However, existing test facilities do not typically allow the user to go back and forth between the business logic itself and object-oriented (OO) methods (referred to equivalently herein as OO scripts) which more directly manipulate the OO objects used by the business logic. That is, once the test facility is animating the procedural business logic which was invoked by the GUI event, processing control remains in that procedural aspect of the test facility until the invoked business logic completes.
The problem with this prior art approach is that the business logic code often needs to directly interact with the OO methods as the business logic executes, rather than awaiting completion of the invoked business logic, such that the two parts of the system (i.e. the GUI part and the business logic part) can execute in an integrated manner. For example, suppose the business logic performs analysis or error checking of data values which an eventual application user will enter into the fields of a user interface panel. Further suppose that this analysis code is designed to display an error message window, at run-time, upon detecting a problem with any of the input data values. Preferably, each detected error would be displayed as it is detected. If the debugger does not return control to the GUI context until all of the business logic corresponding to the invoked GUI event has completed, the error message window will not be displayed at the most appropriate time (and any related OO logic will not execute in-line, before other business logic data processing occurs). This delay between detecting an error and presenting it on the GUI, while control is forced to remain in the business logic being debugged until that code completely finishes, leads to an unnatural, inefficient reflection of the results of the business logic""s processing on the user interface. When this happens, it is much more difficult for the developer to accurately debug the application.
This situation is exacerbated if multiple error messages are generated while stepping through the business logic. Suppose, in this same example, that the application allows the user to enter values of several fields into the GUI before invoking the business logic which analyzes each field value. (This approach may be necessary, for example, when the value of one field dictates the allowable values of another field.) Because the error messages are not presented upon detection, the developer must provide a means for saving each generated message until all the analysis code completes, and a means for then displaying each message in sequence (preferably, in order of the business logic processing). This may be done, for example, by creating a collection or table of error messages as the procedural analysis code executes, and then iteratively processing each saved element of the created structure in the GUI code for display to the user when the analysis code is complete. However, this approach is quite cumbersome and is therefore undesirable.
Alternatively, the developer may be forced to redesign the procedural code to avoid this situation (e.g. by attempting to break the business logic into smaller components, enabling control to return to the GUI more often). This is an undesirable solution, as it makes the coding task more difficult and yields an application design which is oriented toward easier debugging and easier message display, rather than toward the problem being solved by a particular application.
Accordingly, what is needed is a technique for providing seamless debugging of object-oriented methods and procedural language code components which are intended to execute in an integrated manner, where control efficiently passes from one to the other and avoids the problems of prior art debugging facilities. This seamless operation must be provided even though the methods and procedural components may be executing in different processes, different namespaces, and/or different software products.
An object of the present invention is to provide a technique for synchronous execution between objects written in an object-oriented programming language and business logic written in a procedural programming language, while executing under control of an interactive test facility for debugging purposes.
A further object of the present invention is to provide a technique for seamless debugging of object-oriented methods and procedural language code components which are intended to execute in an integrated manner.
Another object of the present invention is to provide this technique whereby control efficiently passes back and forth between object-oriented code execution and procedural language code execution.
Yet another object of the present invention is to provide this technique even though the methods and procedural components may be executing in different processes, different namespaces, and/or different software products.
Still another object of the present invention is to provide a technique for sharing data values among methods and procedural components which may be executing in different processes, different namespaces, and/or different software products.
Other objects and advantages of the present invention will be set forth in part in the description and in the drawings which follow and, in part, will be obvious from the description or may be learned by practice of the invention.
To achieve the foregoing objects, and in accordance with the purpose of the invention as broadly described herein, the present invention provides a method, system, and computer program product for providing synchronous execution between objects written in an object-oriented programming language and business logic written in a procedural programming language, while executing under control of an interactive test facility for debugging purposes. This technique comprises: providing one or more object-oriented methods written in the object-oriented programming language; providing one or more procedural components written in the procedural programming language, wherein at least one of the procedural components contains one or more references to selected ones of the object-oriented methods; selecting, by a user of the interactive test facility, an event from a graphical user interface, wherein the event is operably associated with a selected one of the procedural components; executing the selected procedural component under control of a procedural debugger of the interactive test facility, responsive to the event selection; transferring control from the procedural debugger to a particular one of the object-oriented methods upon encountering one of the references in the executing procedural component, wherein the encountered references identifies that particular one, executing the particular object-oriented method; and returning control to the procedural debugger upon completion of the execution of the particular object-oriented method.
The technique preferably further comprises performing a first synchronization of data values prior to the transferring of control, and performing a second synchronization of data values prior to the returning of control.
The procedural debugger and the object-oriented method may operate in different processes, different namespaces, and/or in different software products.
The technique may further comprise invoking an object-oriented debugger during the execution of the particular object-oriented method, and wherein this object-oriented debugger takes over control of the execution of the particular object-oriented method after the invocation. In this case, the interactive test facility and the object-oriented debugger may be written in different programming languages.